昨天撈出一筆乾淨的證據：GE 從頭到尾零筆 POST，補上 gateway 的兩條路又都被 403 擋下來。今天把這個權限缺口挖到底，順便把這 30 天收個尾。

為什麼權限不夠

這裡要更正我當場的一個誤判。我一開始以為那是「碰不到的別人的專案」，其實不是。那個專案編號對應的 projectId 就是這個帳號 Cloud Shell 的預設專案，帳號確實是這個專案的使用者。

真正的阻擋在組織結構：它掛在一個 organization 底下四層 folder 裡，folder 鏈是 768141529910 → 887824122550 → 824116248379 → 21358131809，帳號有 GE app 的管理權，但沒有 serviceusage.services.enable。

我用 testIamPermissions 打了一發確認，回傳只有兩項：

• discoveryengine.assistants.update
• discoveryengine.engines.update

serviceusage.services.enable 沒有被回傳。resourcemanager.projects.setIamPolicy 也沒有。查 folder 也是 403。

結論：GE 試用租戶拿到的是純應用層權限，基礎設施層一項都沒有。 Agent Gateway 這條路對試用租戶是封閉的，不是設定問題。四層 folder 疊在一個 organization 底下，代表 API 啟用這種基礎設施層級的權限握在組織管理員手上。試用租戶拿到的帳號，從一開始就沒有被授予往上一層動的能力。這跟「忘了勾選某個權限」是完全不同性質的問題，補設定解決不了。

一個反差點，順便一條通則

有意思的是，另一個帳號反而能在同一個專案成功執行 agents.create。

也就是說 discoveryengine 的寫入權有，serviceusage 的權限沒有。兩種權限完全獨立，不要用其中一個推另一個。 我因為「都能寫 agent 了應該也能開 API」浪費了一些時間。

誠實標記

有兩件事我沒驗證，寫在這裡免得被當成結論：

1. 「補上 gateway 之後就會通」未查證。 路徑被權限封死，我做不到那一步。
2. 那個 org 是不是 Google 管理的試用沙箱，是我從專案的自動產生命名樣式加上四層 folder 巢狀推論的，不是查到的。而且沒有可聯絡的管理員這件事也是推論。

帶走的判準

下次遇到 GE 前台打不通：

• 先跑一發 gcloud services enable，一分鐘就知道 gateway 路線可不可行。不要先花時間研究 gateway 的 API 形狀。
• testIamPermissions 只回 discoveryengine 系權限的話，直接說「這條路要換帳號體系」，不要再往 gateway、IAM、service agent 方向查。

這篇為什麼放在系列的最後

因為它是這 30 天裡我最想留下的一段。

前面那些部署步驟明年就過期了。但「零筆請求就別再調 agent 欄位」、「權限用量測不用推論」、「兩種權限互相獨立」這幾條，換一個雲、換一個產品還是成立。

回頭看這 30 天，其實是同一個原則在不同層次反覆出現。

Day 10 到 Day 12 講協定。A2A 只有四個 method，逼你把「agent 之間怎麼溝通」寫成可以測試的規格，取代心照不宣的默契。

Day 23 講框架選型。宣告角色跟明確流程的差別，說穿了也是「流程控制權要不要交出去」的量測問題。交出去省一週的開發時間，換來的是出事時沒有中斷點可下。

Day 20 到 Day 22 的 LangGraph 迴圈跟 checkpointer，一樣是把「這一步該不該重試、能不能停下來等人」寫成可以印出來看的狀態，取代藏在 prompt 裡的默契。

Day 24 到 Day 27 的 Cloud Run 跟 Agent Runtime，踩的坑幾乎都不會報錯。佔位符號、計費參數、忘記刪除，全部要靠主動量測才抓得到，讀輸出不夠。

這兩篇也一樣：前台打不通，先撈日誌看有沒有請求進來，比先調欄位快得多。

這條軸線貫穿協定設計、框架選型、雲端部署、到最後的前台診斷：能量測的事就不要用推論代替，推論留給真的量不到的地方，而且要老實標成推論。 這大概是這 30 天裡，換一個技術堆疊之後還會繼續有用的部分。